With the proliferation of user friendly smart phones and tablets, the usage of high data rate services such as video streaming over the mobile network is becoming commonplace, greatly increasing the amount of traffic in mobile networks. Thus, there is a great urgency in the mobile network community to ensure that the capacity of mobile networks continues to increase with this ever-increasing user demand.
The latest systems, such as the so-called Long Term Evolution (LTE) wireless communications systems developed by the 3rd-Generation Partnership Project (3GPP), can provide spectral efficiencies very close to the theoretical Shannon limit, especially when advanced interference mitigation techniques are used. Two of the most widely used approaches to meet the increasing traffic demands are the continuous upgrading of current networks to support the latest technologies and increasing the density of base stations, i.e., the number of base stations per unit area.
Another approach gaining increased attention is the use of so-called heterogeneous networks, where the traditional, pre-planned deployment of macro base stations (known as the macro layer) is complemented with several low-powered base stations that may be deployed in a relatively unplanned manner. 3GPP has incorporated the concept of Heterogeneous Networks as one of the core items of study in the latest enhancements of LTE, which are covered by Release 11 of the LTE standards. Thus far, several low-powered base stations for realizing heterogeneous networks such as pico base stations, femto base stations (also known as home base stations or HeNBs), relays, and RRHs (remote radio heads) have been defined.
The Evolved UMTS Terrestrial Radio Access Network (E-UTRAN), commonly referred to as the Long-Term Evolution (LTE) network, consists of base stations called enhanced NodeBs (eNBs or eNodeBs), which provide the E-UTRA user plane and control plane protocol terminations towards the end user terminals, known as “user equipment” or “UEs” in 3GPP terminology. FIG. 1 provides a simplified view of the E-UTRAN, as well as components of the Evolved Packet Core (EPC), which provides interconnectivity between the E-UTRAN and public data networks.
As seen in FIG. 1, eNBs 110 communicate with one another by means of the X2 interface, which is defined by a set of communications protocols described by the 3GPP document “Evolved Universal Terrestrial Radio Access Network (E-UTRAN); X2 General Aspects and Principles,” 3GPP TS 36.420, v. 11.0.0 (September 2012). The X2 is an IP interface using Stream Control Transmission Protocol (SCTP) as a transport layer. The eNBs 110 are also connected by means of the S1 interface to the EPC, more specifically to MMEs (Mobility Management Entities) 120 by means of the S1-MME interface and to the Serving Gateway (S-GW, not shown in FIG. 1) by means of the S1-U interface. The S1 interface is described in the 3GPP document “Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 General Aspects and Principles,” 3GPP TS 36.410, v. 11.0.0 (September 2012). The S1 interface supports many-to-many relation between MMEs/S-GWs and eNBs.
The eNBs 110 host functionalities such as Radio Resource Management (RRM), radio bearer control, admission control, header compression of user plane data towards serving gateway, routing of user plane data towards the serving gateway. MMEs 120 are the control nodes that process the signaling between the UE and the core network (CN). The main functions of the MME 120 are related to connection management and bearer management, which are handled via Non Access Stratum (NAS) protocols. The Serving Gateway (S-GW) is the anchor point for UE mobility, and also includes other functionalities such as temporary downlink data buffering while the UE is being paged, packet routing and forwarding of data to the right eNB, gathering of information for charging and lawful interception, etc. The PDN Gateway (P-GW) is the node responsible for IP address allocations to UEs, as well as Quality-of-Service (QoS) enforcement (this is explained in further detail below).
FIG. 2 gives a summary of the functionalities of the eNB 110, MME 120, S-GW 210, and P-GW 220 nodes, and illustrates the functional split between E-UTRAN and the EPC; the reader is referred to 3GPP TS 36.300, v. 11.4.0 (January 2013), and the references therein for the details of the functionalities of the different nodes. Note that in FIG. 2, the larger boxes depict the logical nodes, i.e., the eNB 110, MME 120, S-GW 210, and P-GW 220. The un-shaded boxes therein depict the functional entities of the control plane, while the shaded boxes depict the radio protocol layers.
The radio protocol architecture of E-UTRAN is divided into the user plane and the control plane. FIG. 3 shows the protocol stack for the user-plane, while FIG. 4 shows the control-plane protocol stack.
Referring first to FIG. 3, the user plane protocol stack includes the Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), and Medium Access Control (MAC), all of which are terminated at the eNB 110. The PDCP manages Internet Protocol (IP) packets in the user plane, performing header compression, security, and re-ordering and retransmission during handover. The RLC layer is mainly responsible for segmentation (and corresponding assembly) of PDCP packets, to fit the packet size that is actually to be transmitted over the air interface. RLC can operate either in unacknowledged mode or acknowledged mode, where the latter supports retransmissions. The MAC layer performs multiplexing of data from different radio bearers, and informs the RLC about the size of the packets to provide. This size is decided based on the required quality-of-service (QoS) of each radio bearer and the current capacity available to the UE 310.
FIG. 4 shows the control plane protocol stack. The layers below the Radio Resource Control (RRC) layer perform the same functions as in the user plane, except that there is no header compression in the control plane. The main functions of the RRC are the broadcasting of system information, and RRC connection control, which includes modification, and release of RRC connection, establishment of signaling radio bearers (SRB) and data radio bearers (DRBs), handover, configuration of lower protocol layers, radio link failure recovery, etc. The RRC also manages measurement configuration and reporting. The details of the RRC protocol functionalities and procedures can be found in 3GPP standard 3GG TS 36.331, v. 11.2.0 (January 2013), available at http://www.3gpp.org.
A UE 310 is uniquely identified over the S1 interface by an eNB 110 using an eNB UE S1AP identifier (IP). When an MME 120 receives an eNB UE S1AP ID, it stores it for the duration of the UE-associated logical S1-connection for this UE. Once known to an MME, this information element (IE) is included in all UE-associated S1-AP signaling. The eNB UE S1AP ID is unique within the eNB 110, and each UE 310 is assigned a new S1AP ID after a handover by the target eNB.
From the MME 120 side, a UE is uniquely identified using the MME UE S1AP ID. When an eNB receives MME UE S1AP ID it stores it for the duration of the UE-associated logical S1 connection for this UE. Once known to an eNB, this IE is included in all UE-associated S1-AP signaling. The MME UE S1AP ID is unique within the MME 120, and it is changed if the UE's MME changes, such as would result, for example, from a handover between two eNBs connected to different MMEs.
The flow of user plane and control plane data is illustrated in FIG. 5. There is only one MAC entity per UE, unless the UE supports multiple carriers, as in the case of carrier aggregation, and under this MAC entity, several Hybrid ARQ (HARQ) processes might be running simultaneously, for rapid retransmissions. There is a separate RLC entity for each radio bearer. If the radio bearer is configured to use PDCP, there is also one separate PDCP entity for that bearer. A bearer is configured to use PDCP only if it is dedicated to a UE. In other words, multicast and broadcast data do not utilize PDCP in the control and user planes, and the PDCP is used only for dedicated control messages in the control plane and for dedicated UL/DL data in the user plane.
At the transmitting side, each layer in the illustrated protocol stacks receives a Service Data Unit (SDU) from a higher layer, and sends a Protocol Data Unit (PDU) to the lower layer. For example, PDCP PDUs are sent towards the RLC. These PDCP PDUs are RLC SDUs, from the RLC point of view. The RLC layer in turn sends RLC PDUs towards the MAC; these RLC PDUs are MAC SDUs from the MAC point of view. At the receiving end, the process is reversed, with each layer passing SDUs to the layer above it, where they are perceived as PDUs.
The use of a so-called heterogeneous deployment or heterogeneous network, consisting of network transmission nodes with different transmit powers and with overlapping coverage areas, is considered to be an interesting future deployment strategy for cellular networks. A simplified example of a heterogeneous deployment is illustrated in FIG. 6. In such a deployment, the low-power node 620, often called a “pico node,” is typically assumed to offer high data rates, on the order of megabits-per-second (Mbps) as well as to provide high capacity, as measured in users/m2 or Mbps/m2, in the local areas where this is needed/desired. The high-power node 610, often referred to as a “macro node,” is assumed to provide full-area coverage. In practice, macro nodes may correspond to currently deployed macro cells, while the pico nodes are later deployed nodes, extending the capacity and/or achievable data rates within the macro-cell coverage area where needed. In a typical case, there may be multiple pico nodes within the coverage area of a macro node.
A pico node of a heterogeneous deployment may correspond to a cell of its own, which is often referred to as a “pico cell.” This means that, in addition to downlink and uplink data transmission and reception, the pico node also transmits the full set of common signals/channels associated with a cell. In the LTE context, this includes:                The Primary and Secondary Synchronization Signals (PSS and SSS), corresponding to the Physical Cell Identity of the pico cell.        The Cell-specific reference signals (CRS), also corresponding to the Physical Cell Identity of the cell. The CRS can be used for downlink channel estimation, for example, to enable coherent demodulation of downlink transmissions.        The Broadcast channel (BCH), with corresponding pico-cell system information. Note that additional system information is transmitted on the Physical Downlink Shared Channel (PDSCH).        
FIG. 7 illustrates an example pico cell 720 that operates as a cell of its own. The indices “p” and “m” indicate common signals/channels for the pico and macro cell respectively. As the pico node in this case transmits the common signals/channels, the corresponding pico cell can be detected and selected (connected to) by a terminal (UE, user equipment).
If the pico node corresponds to a cell of its own, so-called L1/L2 control signaling on the Physical Downlink Control Channel (PDCCH), as well as on the Physical Control Format Indicator Channel (PCFICH) and the Physical Hybrid Indicator Channel (PHICH) are transmitted from the pico node to connected terminals, in addition to downlink data transmission on the PDSCH. The L1/L2 control signaling provides downlink and uplink scheduling information and hybrid-ARQ-related information to terminals within the cell.
Alternatively, a pico node within a heterogeneous deployment may not correspond to a cell of its own but may only provide a data-rate and capacity “extension” of the overlaid macro cell. This is sometimes known as “shared cell” or “soft cell”. In this case, at least the CRS, PBCH, PSS and SSS are transmitted from the macro node. The PDSCH can be transmitted from the pico node. To allow for demodulation and detection of the PDSCH, despite the fact that no CRS is transmitted from the pico node, demodulation reference symbols (DM-RS) should be transmitted from the pico node together with the PDSCH. These UE-specific reference signals can then be used by the terminal for PDSCH demodulation/detection. This is shown in FIG. 8, which illustrates a pico node 820 that provides a pico beam but is part of the macro cell.
Transmitting data from a pico node that does not transmit CRS, as described above, requires DM-RS support in the terminal. Terminals that support DM-RS may be referred to as “non-legacy terminals” herein. In LTE, DM-RS-based reception of the PDSCH is supported in Release 10 of the 3GPP specifications, for the Frequency-Division Duplexing (FDD) mode of operation. Support for DM-RS-based reception of L1/L2 control signaling is planned for Release 11 of the 3GPP specifications. For terminals that do not support DM-RS-based reception, i.e., “legacy terminals,” one possibility in a shared cell setting is to exploit Single-Frequency Network (SFN) transmission. In essence, according to this approach identical copies of those signals and channels that are necessary for a legacy terminal are transmitted simultaneously from the macro and pico nodes. From a terminal perspective this will look as a single transmission. Such an operation, which is illustrated in FIG. 9, provides gains in signal-to-interference-plus-noise ratio (SINR) at the receiver of UE 310, which can be translated into a higher data rate, but does not otherwise provide overall capacity improvements, since transmission resources cannot be reused across sites within the same cell.
An important aspect of any mobile communication system is handover, where the system tries to assure service continuity of the User Equipment (UE) by transferring the connection from one cell to another, depending on several factors such as signal strength, load conditions, service requirements, etc. The provision of efficient and effective handovers, e.g., involving a minimum number of unnecessary handovers, a minimum number of handover failures, minimum handover delays, etc., affects not only the quality-of-service (QoS) experienced by the end user, but also the overall mobile network capacity and performance.
In LTE, UE-assisted, network-controlled handover is utilized. The 3GPP document “Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2,” 3GPP TS 36.300, v. 10.7.0 (March 2013), available at http://www.3gpp.org, may be consulted for further details. This handover is based on UE reports, and the UE is moved, if required and when possible, to the most appropriate cell that will assure service continuity and quality.
Handover (HO) is performed via the X2 connection, whenever available, and if not, using S1 (i.e., involving the Core Network (CN)). The X2 Handover process is shown in FIG. 10. As seen in FIG. 10, the handover procedure can be sub-divided into three stages of preparation (initiation), execution and completion.
Referring to the numbered messages in FIG. 10, it can be seen that principal steps of the handover process are as follows:                1. The source eNB 110-S configures the UE measurement procedures. This can be done either when the UE first connects to an eNB (in which case the configuration information is included in the HO command, as described later) or later on by sending measurement reconfiguration messages. The measurement configurations are sent to the UE 310 using the measConfig Information Element (IE) that is included in the RRCConnectionReconfiguration message.        2. The UE 310 is triggered to send a measurement report by the measurement rules set as described immediately above.        3. Based on the received measurement report and other Radio Resource Management (RRM) information, the source eNB 110-S makes a decision to hand over the UE to the target eNB 110-T.        4. The source eNB 110-S issues a HANDOVER REQUEST message to the target eNB 110-T, passing necessary information to prepare for the HO at the target side. The source eNB 110-S must indicate the cause of the HO in this message, which can be, e.g.,                    a. Handover Desirable for Radio Reasons,            b. Resource Optimization Handover,            c. To reduce Load in Serving Cell                        5. Admission Control may be performed by the target eNB 110-T.        6. The target eNB 110-T prepares for HO at Layers 1 and 2 (L1/L2), and sends the HANDOVER REQUEST ACKNOWLEDGE to the source eNB 110-S. The HANDOVER REQUEST ACKNOWLEDGE message includes an Information Element (IE) called “Target eNB to Source eNB Transparent Container”. This IE basically contains the handover command message (RRCConnectionReconfiguration that includes the mobilityControlInfo IE) that is sent to the UE 310 in the next step. As soon as the source eNB 110-S receives the HANDOVER REQUEST ACKNOWLEDGE, or as soon as the transmission of the handover command is initiated in the downlink, user plane data forwarding may be initiated.        7. The source eNB 110-S sends the handover command (i.e., the RRCConnectionReconfiguration message including mobilityControlInfo) towards the UE 310, on behalf of the target eNB 110-T.        8. The source eNB 110-S sends the SN (Sequence Number) STATUS TRANSFER message to the target eNB 110-T. The STATUS TRANSFER message includes the ID of the impacted EPS radio bearers (E-RABs) and PDCP SNs for uplink and downlink data transfers.        9. After receiving the RRCConnectionReconfiguration message, including the mobilityControlInfo, the UE 310 performs synchronization to target eNB 110-T and accesses the target cell via the random access channel (RACH). If the received RRCConnectionReconfiguration contained dedicated RACH information, the dedicated preamble included in there is used for the RACH access. Otherwise, a contention-based approach is taken. The UE 310 also configures the lower layer protocol stacks based on the received configuration information.        10. The target eNB 110-T responds with uplink (UL) allocation and timing advance (TA).        11. When the UE 310 has successfully accessed the target cell, the UE sends the RRCConnectionReconfigurationComplete message to the target eNB 110-T to confirm that the handover succeeded. Optionally, the UE 310 can indicate to the target that it has information regarding earlier Radio Link Failure (RLF) or other logged measurements that could be used for optimization purposes. After the confirmation is received, the target eNB 110-T can begin sending data to the UE 310 and the UE 310 can send data to the target based on the scheduling grants it is receiving. However, the data from the core network is still routed to the source eNB 110-S.        12. The target eNB 110-T sends a PATH SWITCH REQUEST message to the MME 120, to inform it that the UE 310 has changed the cell. Table 1, below, shows the contents of the PATH SWITCH REQUEST message. If not all the UE bearers are included in the E-RAB To Be Switched in Downlink List, the MME 120 considers the non-included E-RABs as implicitly released by the eNB (3GPP TS 36.413, v. 11.2.1 (February 2013)). That is, normal operation is for the target eNB 110-T to list only those bearers that it has admitted during admission control and that it has communicated earlier to the source via the HANDOVER REQUEST ACKNOWLEDGE message. The MME 120 releases the non-accepted dedicated bearers by triggering bearer release procedures (3GPP TS 23.401, v. 11.5.0 (March 2013)).        13. The MME 120 sends a MODIFY BEARER REQUEST message to the Serving Gateway 210. The MME 120 includes the bearers to be switched to the new target in the “Bearer contexts to be modified” field and the ones not received in the PATH SWITCH REQUEST message in the “Bearer context to be removed” field of the MODIFY BEARER REQUEST message (3GPP TS 29.274, v. 11.6.0 (March 2013)).        14. The Serving Gateway 210 switches the downlink data path to the target side. That is, it starts sending downlink packets to the target eNodeB 110-T using the newly received address and TEIDs (3GPP TS 23.401, v. 11.5.0 (March 2013)). The Serving Gateway 210 sends one or more “end marker” packets on the old path to the source eNB 110-S and then can release any U-plane/TNL resources towards the source eNB 110-S.        15. The Serving Gateway 210 sends a MODIFY BEARER RESPONSE message to MME 120.        16. The MME 120 confirms the PATH SWITCH REQUEST message with the PATH SWITCH REQUEST ACKNOWLEDGE message. Table 2 shows the contents of this message.        17. By sending the UE CONTEXT RELEASE message, the target eNB 110-T informs success of HO to source eNB 110-S, and triggers the release of resources by the source eNB 110-S.        18. Upon reception of the UE CONTEXT RELEASE message, the source eNB 110-S can release radio and C-plane related resources associated to the UE context. Any ongoing data forwarding may continue.        
TABLE 1IE type andSemanticsAssignedIE/Group NamePresenceRangereferencedescriptionCriticalityCriticalityPATH SWITCH REQUEST message.Message TypeM9.2.1.1YESrejecteNB UE S1AP IDM9.2.3.4YESrejectE-RAB To Be1YESrejectSwitched inDownlink List>E-RABs1 toEACHrejectSwitched in<maxnoofDownlink ItemE-RABs>IEs>>E-RAB IDM9.2.1.2—>>TransportM9.2.2.1—layer address>>GTP-TEIDM9.2.2.2To deliver DL—PDUsSource MME UEM9.2.3.3YESrejectS1AP IDE-UTRAN CGIM9.2.1.38YESignoreTAIM9.2.3.16YESignoreUE SecurityM9.2.1.40YESignoreCapabilitiesCSG IdO9.2.1.62YESignoreCell AccessO9.2.1.74YESignoreModeSource MMEO9.2.3.9YESignoreGUMMEIPATH SWITCH REQUEST ACKNOWLEDGE message.Message TypeM9.2.1.1YESrejectMME UE S1AP IDM9.2.3.3YESignoreeNB UE S1AP IDM9.2.3.4YESignoreUE AggregateO9.2.1.20YESignoreMaximum BitRateE-RAB To Be0..1YESignoreSwitched inUplink List>E-RABs1 toEACHignoreSwitched in<maxnoofUplink Item IEsE-RABs>>>E-RAB IDM9.2.1.2—>>TransportM9.2.2.1—Layer Address>>GTP-TEIDM9.2.2.2—E-RAB To BeOE-RAB Lista value for E-YESignoreReleased List9.2.1.36RAB ID shallonly be presentonce in E-RABTo Be Switchedin Uplink List IE +E-RAB to BeReleased List IESecurity ContextM9.2.1.26One pair ofYESreject{NCC, NH} isprovidedCriticalityO9.2.1.21YESignoreDiagnosticsMME UE S1AP ID 2O9.2.3.3This IE indicatesYESignorethe MME UES1AP IDassigned by theMME
Discussions regarding the enhancements to LTE that are planned for Release 12 are underway. One of the proposed items for study is the possibility of serving a User Equipment (UE) from more than one eNB simultaneously. However, the current legacy handover mechanisms of LTE must be updated in order to support this.